Про отказоустойчивые архитектуры

Дмитрий Масленников, «Т-Банк»

CAP теорема

Consistency, Availability, Partitioning — можно гарантировать только 2 из этих свойств

Consistency

Читаем самую последнюю запись

Availability

Система всегда отвечает (без ошибок). Ответ самыми свежими данными не гарантируется.

Partitioning

Система сохраняет гарантии при потерях на сети

Следствие

Если нельзя создать надежную, консистентную систему, то надо дизайнить то, как система будет ломаться.

Частота и длительность сбоев важны для пользовательского опыта, но теорема их никак не учитывает.

Являются ли клиенты частью системы?

Связь между клиентом и серверами чатсо теряется — проблема связности становится намного более серьезной

Всегда ли нужна доступность?

Всегда ли нужна консистентность?

Week Consistency

Eventual Consistency

Если перестать менять состояние, то через какое-то время она придет в консистентное состояние: все записи применены в правильном порядке

Session Consistency

Read Own Writes

Мы видим все свои записи в одной и той же сессии

Write Follows Read

Если перед записью (W2) мы делали чтение, которое показало эффект предыдущей записи (W1), то вторая запись (W2) должна всегда быть после предыдущей (W1)

Monotonic Write

Все записи одной сессии применяются строго по порядку

Monotonic Read

Мы не можем вычитать состоянее старее, чем мы уже читали

Consistent Prefix Read

Если мы читаем состояние после некоторой записи, то в нем должны учитываться все предыдущие записи.

Вывод

Нам не всегда нужна строгая консистенстность на практике

PACELC теорема

If Partitioning then Availability or Consistency Else Latency or Consistency

Распределенные системы среди нас

Взятие идей из не IT-систем. «Метод маленьких человечков»

Микросервисы

Недостатки

  • Сетевой вызов медленный — увеличивает время ответа
  • Лишние сериализации/десериализации — нужно больше CPU
  • Необходим дополнительный мониторинг (ресурсы)
  • Надо писать логику по повторам, балансировке и подобное
  • Необходимо держать обратную совместимость между контрактами
  • Сложнее обучать архитектуре, сложнее искать ошибки
  • Сложнее профилировать, трассировать запросы, отлаживать

Преимущества

  • Независимый цикл релизов
  • Фатальная ошибка в одной части не приветет к падению другой
  • Независимое время жизни — части можно останавливать и рестартовать независимо
  • Одной из частей можно гарантировать доступные ресурсы

Спасибо!

Вопросы?